Messaging systems such as IBM(R) WebSphere(R) MQ can deliver messages to an input (application) queue of a server program. The server program is then able to remove (read destructively) such messages and action them.
It is often a requirement that instances of the server program are created dynamically, as and when needed, in order to maintain some performance objective. For example, a first instance is typically created when there is some work for the instance to do (i.e. a message has been delivered to server's application queue) and additional instances are created when the number in existence is not enough to provide a timely service.
IBM's WebSphere MQ messaging product provides a facility known as “triggering” which helps to achieve this requirement. In triggering, certain queues are monitored (those designated as “triggered”) for particular transitions. These transitions are specified by users and can be, for example, a transition from queue empty to queue not empty.
When such a transition occurs, a “trigger message” is created containing details of the transition and the trigger message is put onto an initialisation queue. The initiation queue is typically specified by a user as an attribute of a triggered queue.
By reading trigger messages from initiation queues, special programs known as trigger monitors are able to decide if a new server instance is required to process messages. If a new instance is required, then one is created.
A problem with this is how to decide if a new server instance is required. Ways to do this include monitoring the extent to which existing server instances are achieving performance targets and monitoring resource utilization by existing server instances.
WebSphere MQ SupportPac™ MA0L (available from www.ibm.com/software/ts/mqseries/txppacs/ma01.html) uses queue depth (i.e. the number of messages on the queue) to decide when to start a new server instance. (Another example of this can be found in U.S. Pat. No. 5,799,173.) A system using this solution will however react to transient peaks rather than to actual increases in workload.
For most real-world scenarios, the number of pending service requests is subject to large short-term fluctuations. For example, one server instance might be processing messages from a queue A. If an application batches and puts 500 messages to queue A, this sudden increase in work might cause an additional 5 server instances to be created. The workload on the queue may then return to a typical rate of 10 messages on the queue at any one time. In other words, the increase in work is very short term and consequently the newly created 5 server instances are no longer necessary.
Creation and termination of server instances is costly both in terms of processing power and time. It is therefore desirable to avoid unnecessary creation of sever instances, whilst optimising the number necessary for timely processing of an application queue.
(More detail on triggering in a WebSphere MQ environment can be obtained from WebSphere MQ Application Programming Guide, IBM Publication number SC34-6064.)
There are also alternatives to triggering. For example, the z/OS™ operating system (available from IBM Corporation) provides a Workload Manager (WLM) which monitors resource utilization (e.g. CPU usage)
However it has been determined that queue depth is a far more accurate method for determining when a new server instance is required. However queue depth does not take account of transient workload.
A system is desired which will react to trends in workload rather than to random (atypical) fluctuations.